home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000098_owner-urn-ietf _Sun Mar 30 14:27:43 1997.msg < prev    next >
Internet Message Format  |  1997-04-01  |  3KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id OAA29662
  3.     for urn-ietf-out; Sun, 30 Mar 1997 14:27:43 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id OAA29657
  6.     for <urn-ietf@services.bunyip.com>; Sun, 30 Mar 1997 14:27:41 -0500 (EST)
  7. Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA26622  (mail destined for urn-ietf@services.bunyip.com); Sun, 30 Mar 97 14:27:39 -0500
  9. Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id NAA08272; Sun, 30 Mar 1997 13:27:41 -0600 (CST)
  10. From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  11. Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id NAA01010; Sun, 30 Mar 1997 13:27:37 -0600 (CST)
  12. Date: Sun, 30 Mar 1997 13:27:37 -0600 (CST)
  13. Message-Id: <199703301927.NAA01010@void.ncsa.uiuc.edu>
  14. To: Dan Connolly <connolly@w3.org>
  15. Cc: urn-ietf@bunyip.com
  16. Subject: [URN] urn: prefix is a brand name?
  17. In-Reply-To: <333CE042.7721AF9F@w3.org>
  18. References: <333CE042.7721AF9F@w3.org>
  19. Sender: owner-urn-ietf@Bunyip.Com
  20. Precedence: bulk
  21. Reply-To: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  22. Errors-To: owner-urn-ietf@Bunyip.Com
  23.  
  24. Dan Connolly writes:
  25.  > I found another one of the motivations for the urn: prefix,
  26.  > (thanks for the pointer to the WAIS archive!)
  27.  > and it worries me more than any of the other so far:
  28.  > 
  29.  > On Tue, 05 Nov 1996 23:16:17 -0500, Keith Moore wrote:
  30.  > >This is why URNs need a URN: prefix -- because a lot of the value in
  31.  > >having a URN name space with those properties is so *humans* can
  32.  > >recognize a URN when they see it.
  33.  
  34. We got to that point after my persistent (ha!) arguments that "urn:"
  35. doesn't mean much else.  Not everyone agrees with Keith on this point,
  36. of course.
  37.  
  38. Ironically, Keith and others also argue for semantically meaningless
  39. numeric URNs and a higher layer of human friendly identifiers, so humans
  40. will hopefully never see the "urn:" prefix.
  41.  
  42. I think the real value of "urn:" has nothing to do with the notion of
  43. names, but that it is associated with a new resolution mechanism, the
  44. NAPTR mechanism. And the reason this is valuable is that it is very
  45. hard to deploy any new resolution mechanism whatsoever.  But once
  46. deployed, this mechanism is general enough that it can be applied to
  47. all URIs, so the prefix might as well have been "uri:".
  48.  
  49. I recognize that this association between "urn:" and the NAPTR
  50. mechanism is contrary to the intent of the working group, but intent
  51. is irrelevant compared to actual practice.
  52.  
  53. --
  54. Daniel LaLiberte (liberte@ncsa.uiuc.edu)
  55. National Center for Supercomputing Applications
  56. http://union.ncsa.uiuc.edu/~liberte/